Files and file operations, such as read, write, open, close, and the like are familiar with computer users and programmers. Because of this familiarity, the file system paradigm has been employed to monitor and manage other processes and entities, which may not, at first glance, be thought of as data storage files.
For example, one of the main functions of an operating system is to manage tasks or processes executed in a computer system. If the data pertaining to the tasks or processes can be represented as files, these tasks or processes can be monitored and/or manipulated and/or controlled using the familiar file system commands. In UNIX, for example, there is provided a process file system or ProcFS to manage the interactions between the applications and the tasks/processes, which have been modeled by files in order to allow the applications to monitor and/or control the tasks/processes using the familiar file system user command and application program interface.
To facilitate discussion, FIG. 1 illustrates a typical ProcFS arrangement in which a ProcFS 102 is employed to facilitate the interactions between applications 104 and a plurality of kernel subsystems 106, 108, 110 and 112. Within each kernel subsystem, there is provided one or more internal kernel data structures, which reflect the status of the associated kernel subsystem and contain information that ProcFS 102 wishes to monitor and/or control. These internal kernel data structures are shown for kernel subsystems 106, 108, 110 and 112 as respective internal kernel data structures 114, 116, 118 and 120.
In the example of FIG. 1, kernel subsystem 106 represents a file descriptor subsystem, which deals with the set of open files for processes in the system. Kernel subsystem 108 represents the scheduler subsystem, which schedules execution entities in the system. Kernel subsystem 110 represents the task/process subsystem, which manages the creation and destruction of threads, processes, and tasks in the system. Kernel subsystem 112 represents the virtual memory subsystem, which manages virtual and/or real memory for the processes. ProcFS 102 and the various kernel subsystems may reside in the operating system's kernel space. Unlike other file systems, the end user cannot add, delete, and modify files in ProcFS.
ProcFS 102 includes a plurality of pseudo-files whose contents are created based on the internal kernel data structures of their respective kernel subsystems. That is, a pseudo-file that is associated with a kernel subsystem reflects the data in the internal data kernel structure of its associated kernel subsystem. If the data within internal kernel data structure 114 of kernel subsystem 106 changes, for example, the content of pseudo-file 130, which is associated with kernel subsystem 106, would correspondingly change.
When an application makes a call into ProcFS 102 to request monitoring and/or controlling one of the kernel subsystems, ProcFS 102 opens the pseudo-file(s) the application is interested in and allows the application to access the contents of the appropriate pseudo-file(s) in order to monitor the operation of the associated task/process in the relevant kernel subsystem and/or to control its operation by writing parameters, for example.
Although the ProcFS arrangement of FIG. 1 (and its variations) has been in use for some time, there are disadvantages. One of the main disadvantages of the ProcFS arrangement of FIG. 1 relates to the monolithic nature of ProcFS 102. In ProcFS 102, the set of pseudo-files (e.g., pseudo-files 130, 132, 134 and 136) as well as the content, format, and file directory hierarchy of each, is determined by the OS engineers at the time of OS creation and is fixed at the time of OS creation. If one of the kernel subsystems is modified, or a new kernel subsystem is desired, ProcFS 102 must be modified as a single unit.
Because there is no industry standard that governs the content, file format, and file directory hierarchy of ProcFS 102, different vendors implement ProcFS 102 differently, and even the same vendor may implement ProcFS 102 differently from version to version. Thus, when a user wishes to make changes to one of the kernel subsystems or wishes to introduce a new kernel subsystem, the OS engineers who originally designed ProcFS 102 may need to be consulted. Because of the complex nature of operating systems and its various subsystems, it is generally the case that different teams within the company that supplies the OS may need to coordinate in order to change ProcFS 102.
This situation is conceptually illustrated in exemplary FIG. 2, wherein ProcFS team 202 must coordinate with file system team 204, process management team 208, virtual memory team 210, as well as with individuals outside of OS company 212 (such as one or more independent software vendors, ISV 214) in order to create an updated or a new ProcFS 216. The complexity involved in making a change to the prior art ProcFS often results in an undue amount of delay in delivering the updated ProcFS to the customer requesting the change, thus giving rise to customer dissatisfaction.
Furthermore, when application 104 of FIG. 1 makes a call into ProcFS 102, the resultant query into pseudo-file 130 crosses subsystem boundaries. This is an undesirable data coupling behavior from a modularity point of view, which behavior is a direct result of the monolithic nature of ProcFS 102. The data coupling makes maintenance and update of ProcFS 102 unnecessarily complex as well reducing its overall reliability.
Additionally, prior art ProcFS's tend to be designed to work in a single operating environment at a given point in time and is typically specific to a particular version of the operating system by a particular vendor. There are times, however, that a customer may wish to concurrently execute different applications, each of which being associated with a different operating system, a different version, and/or a different vendor, on a given computer system and to have the ability to employ the ProcFS to monitor/control the various kernel subsystems. It would be desirable to provide a ProcFS that is compatible with those multiple applications and to allow the different applications to access such a ProcFS without requiring the applications to be reprogrammed to use a different ProcFS pathname and/or without requiring rebooting a differently configured system.